home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-uri-resource-names-00.txt < prev    next >
Encoding:
Text File  |  1993-06-07  |  9.6 KB  |  240 lines
  1. INTERNET--DRAFT                        Chris Weider
  2. IETF URI Working Group                    Merit Network, Inc.
  3.                             Peter Deutsch
  4.                             Bunyip Information
  5.                               Systems, Inc.
  6.                             May, 1993
  7.  
  8.         Uniform Resource Names
  9.  
  10. Status of this Memo
  11.  
  12. In this paper, the authors propose an identifier, call the Uniform Resource
  13. Name (URN), which is designed to provide persistent naming for resources
  14. and objects on the Internet.
  15.  
  16.         This document is an Internet Draft.  Internet Drafts are working
  17.         documents of the Internet Engineering Task Force (IETF), its Areas,
  18.         and its Working Groups.  Note that other groups may also distribute
  19.         working documents as Internet Drafts.
  20.  
  21.         Internet Drafts are draft documents valid for a maximum of six
  22.         months. Internet Drafts may be updated, replaced, or obsoleted
  23.         by other documents at any time. It is not appropriate to use 
  24.         Internet Drafts as reference material or to cite them other than
  25.         as a "working draft" or "work in progress."
  26.  
  27.         Please check the I-D abstract listing contained in each Internet
  28.         Draft directory to learn the current status of this or any 
  29.         other Internet Draft.
  30.  
  31.     This Internet Draft expires November 10, 1993.
  32.  
  33.  
  34. 1: Introduction
  35.  
  36. A Uniform Resource Name (URN) is an identifier which can be used to uniquely
  37. identify a resource, and is designed to provide persistent naming for 
  38. networked objects.  This name would stay the same no matter what the 
  39. current location(s) of the object was.
  40.  
  41. 2: Motivation
  42.  
  43. This work comes out of the discussions held at the Uniform Resource Identifier
  44. meetings at the IETF, and from further discussions among interested parties.
  45. Currently, the only standard identification scheme for resources on the Net is
  46. the Uniform Resource Locator (URL) [Berners-Lee 1993]. This "Locator"
  47. is designed to provide a uniform way of specifying location and retrieval 
  48. information for networked objects. The URL, however, will not provide a stable,
  49. long-lived reference to a resource as the resources have a bad habit of moving 
  50. out from under the locator. Also, a given resource may have multiple URLs if
  51. it resides at a number of different locations on the net, or is available
  52. under a number of different access methods. Thus it is difficult to tell,
  53. given two different URLs, whether the resources they point to are the same
  54. or different without retrieving both of them. The Uniform Resource Name, or 
  55. URN, has been designed to alleviate these problems.
  56.  
  57. 3: The Uniform Resource Name (URN)
  58.  
  59. 3.1 Functionality
  60.  
  61. The URN is designed to provide persistent naming for objects on the net. It
  62. is intended to be used in conjunction with a directory service, which can 
  63. provide a URN -> URL mapping [Weider 1993]. This URN-URL architecture allows 
  64. permanent references to be made to resources without worrying about their 
  65. current locations. It is also intended to provide some detection of duplicates 
  66. in responses to queries of various resource location services. 
  67.  
  68. INTERNET--DRAFT          Uniform Resource Names            Weider, Deutsch
  69.  
  70.  
  71. 3.2 What URNs are *not*
  72.  
  73. URNs are not intended to be human-readable in the sense that a human could
  74. look at the URN and determine anything about the contents of the resource.
  75. While the Naming Authority (q.v.) has the final determination of the contents
  76. (subject to the syntax constraints), the Naming Authority is STRONGLY
  77. discouraged from placing metainformation about the resource into the resource's
  78. URN, as the URNs are not expected to be read, and because this paper will
  79. specify only four consistent components of the URN. Although there have been a 
  80. number of proposals placing extensive semantics on the contents of the URN 
  81. [Spero 1992, Kunze 1993], it was decided by the authors of all the proposals
  82. that all metainformation should be conveyed using another mechanism, and that 
  83. the Naming Authority should assume that humans will never look at the contents 
  84. of the URN to determine qualities of the resource they are retrieving, and 
  85. would not be required to guess from a given URN the URN of a document which 
  86. might be related.
  87.  
  88. 3.3 Components of the URN
  89.  
  90. There are three components to the URN; a wrapper, a Naming Authority identifier,
  91. and an opaque 'name'. The general syntax is:
  92.  
  93.  
  94.     URN:Naming_Authority_identifier::opaque_string:::
  95.  
  96.          ^  |                          ^             | ^
  97.          |_________________ wrapper ___|_______________|
  98.  
  99. Blanks, <crlf>s, and non-printing characters are NOT allowed. For a full
  100. allowable character set, see section 5.
  101.  
  102. 3.3.1 The wrapper
  103.  
  104. The wrapper consists of the 4 character header 'URN:', two consecutive
  105. colons to separate the Naming_Authority_Identifier component from the 
  106. opaque_string component, and the 3 character trailer ':::'.
  107.  
  108. 3.3.2 The Naming Authority Identifier
  109.  
  110. The Naming Authority identifier consists of two sub-components, a 'scheme
  111. identifier' and an 'individual identifier'. A scheme identifier is the
  112. name of a protocol or organization which can guarantee the uniqueness and
  113. resolvability of the individual identifier. The individual identifier is
  114. the identifier of an organization which has assigned the opaque string 
  115. component to the resource and can resolve the URN to a set of URLs for the
  116. resource. The scheme identifier and the individual identifier are separated by
  117. a colon. For example, typical Naming Authorities might be 
  118.  
  119.        IANA:42117
  120.  
  121. or
  122.  
  123.      ISBN_Publisher_ID:0_201_12
  124. etc.
  125.  
  126. 3.3.3 The Opaque String
  127.  
  128. The opaque string component of the URN is any string the Naming Authority 
  129. wishes to assign to a given resource, subject only to the syntax description
  130.  
  131.  
  132. INTERNET--DRAFT           Uniform Resource Names                Weider, Deutsch
  133.  
  134.  
  135. below. As mentioned above, the Naming Authority should not assume that a 
  136. human will ever read the URN. Also, the Naming Authority, in assigning an
  137. opaque string to a given resource, should keep the following guidelines in 
  138. mind:
  139.  
  140.       1: A given opaque string should be case-insensitive (for compatibility
  141.        with very old systems).
  142.  
  143.     2: A given opaque string, once assigned, should never be reused. These
  144.        are expected to be persistent names for resources (think in terms
  145.        of decades).
  146.  
  147.     3: In assigning an opaque string, and thus creating a URN, the Naming
  148.        Authority should make provisions for a URN -> URL mapping
  149.        function. This need be nothing more than finding an organization
  150.        which is already providing this service for other URNs and making
  151.        arrangements to have them translate for the new URN, or could
  152.        be as involved as creating a new software agent to provide this
  153.        service.  Remember that a name is no good without some way of 
  154.        getting a location.
  155.  
  156.     4: URNs will be returned as pointers from a resource location service.
  157.        (See [Weider 1993]). Consequently, a Naming Authority should give
  158.        some thought to the assignation of new URNs for resources which
  159.        are derived in some fashion from other resources to which that
  160.        Authority has already assigned URNs. For example, should the
  161.        Postscript version and the ASCII version of a paper have the
  162.        same URN? While there are no universally applicable answers to
  163.        questions like these (for example, should the Russian and English
  164.        versions of a scientific paper have the same URN?) an Authority
  165.        should keep in mind that users will want to weed out duplicate
  166.        resources in the lists of URNs returned by a resource location
  167.        service, and consequently will be doing a lot of equality testing
  168.        on the URNs.
  169.  
  170.     
  171. 4: Setting up as a Naming Authority
  172.  
  173. There are 2 scheme identifiers listed here; others will no doubt be suggested
  174. and added as this draft circulates. They are:
  175.  
  176.         IANA
  177.         ISBN_Publisher_ID
  178.  
  179. To set one's organization up as a Naming Authority, one can use the ISBN 
  180. publisher ID one has been assigned, or one can apply for an Enterprise
  181. Number from the IANA (Internet Assigned Number Authority) if the organization
  182. does not already have one. The general syntax is listed in section 5.
  183.  
  184. 5: Syntax
  185.  
  186. Below is a BNF like description of the syntax of the URN. Spaces have 
  187. been used here to separate components for readability, spaces are NOT ALLOWED
  188. in a syntactically correct URN. Square brackets '[' and ']' are used to
  189. indicate optional parts; a vertical line "|" indicates alternatives.
  190. Single letters and digits stand for themselves. All words of more than one
  191. letter are either expanded further in the syntax or represent themselves.
  192.  
  193.  
  194. INTERNET--DRAFT           Uniform Resource Names                Weider, Deutsch
  195.  
  196.  
  197. urn            URN: Authority_Id :: opaque_string :::
  198. Authority_Id        Scheme_ID [ : Individual ]
  199. Scheme_ID        IANA | ISBN_Publisher_ID
  200. Individual        xalphas
  201. opaque_string        xalphas
  202. xalphas            xalpha [ xalphas ]
  203. xalpha            a | b | c | d | e | f | g | h | i | j | k | l |
  204.             m | n | o | p | q | r | s | t | u | v | w | x |
  205.             y | z | A | B | C | D | E | F | G | H | I | J |
  206.             K | L | M | N | O | P | Q | R | S | T | U | V |
  207.             W | X | Y | Z | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
  208.             9 | 0 | - | _ | . | @
  209.  
  210. 6: References
  211.  
  212. [Kunze 1993]  Kunze, John, Resource Citations for Electronic Discovery and 
  213.           Retrieval, March, 1993. Circulated to ietf-uri mailing list.
  214.  
  215. [Spero 1992]  Spero, Simon, Uniform Resource Numbers, November 1992. 
  216.           Circulated to ietf-uri mailing list.
  217.  
  218. [Weider 1993] Weider, Chris and Deutsch, Peter. A Vision of an Integrated 
  219.           Internet Information Service, March, 1993. Available as
  220.  
  221. ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-iiir-vision-00.txt
  222.  
  223. 7: Author's addresses
  224.  
  225. Chris Weider
  226. clw@merit.edu
  227. Merit Network, Inc.
  228. 2901 Hubbard, Pod G
  229. Ann Arbor, MI 48109
  230. Phone: (313) 747-2730
  231. Fax: (313) 747-3185
  232.  
  233. Peter Deutsch
  234. peterd@bunyip.com
  235. Bunyip Information Systems
  236. 310 St-Catherine St West
  237. suite 202,
  238. Montreal, Quebec H2X 2A1
  239. CANADA
  240.